Tom Rini [Tue, 21 Jan 2020 16:53:38 +0000 (11:53 -0500)]
[PATCH] cmd/gpt: Address error cases during gpt rename more correctly
New analysis by the tool has shown that we have some cases where we
weren't handling the error exit condition correctly. When we ran into
the ENOMEM case we wouldn't exit the function and thus incorrect things
could happen. Rework the unwinding such that we don't need a helper
function now and free what we may have allocated.
Fixes: 18030d04d25d ("GPT: fix memory leaks identified by Coverity") Reported-by: Coverity (CID: 275475, 275476) Cc: Alison Chaiken <alison@she-devel.com> Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Cc: Jordy <jordy@simplyhacker.com> Signed-off-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Gbp-Pq: Topic security
Gbp-Pq: Name CVE-2020-8432-cmd-gpt-Address-error-cases-during-gpt-rename-more-c.patch
The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
to Kconfig.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name qemu-riscv64_smode-sifive-fu540-fix-extlinux-define-.patch
Leigh Brown [Wed, 27 Feb 2019 11:32:16 +0000 (11:32 +0000)]
[PATCH] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug
Hello,
Vagrant Cascadian asked for people to test the version of u-boot packaged
for Debian Buster. I tested u-boot on my Dreamplug and found it was not
working correctly. I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.
The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
I don't have much knowledge of ARM caching, but the following patch makes
it work again on my Dreamplug.
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name Commit-ARM-CPU-arm926ejs-Consolidate-cache-routines-.patch
XOM pins provide information for iROM bootloader about the boot device.
Those pins are mapped to lower bits of OP_MODE register (0x10000008),
which is common for all Exynos SoC variants. Set the default MMC device id
to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
the eMMC).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0007-arm-exynos-Read-default-MMC-device-from-XOM-7-5-pins.patch
Marek Szyprowski [Thu, 16 Jan 2020 15:25:35 +0000 (16:25 +0100)]
[PATCH 4/5] arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
Use MMC0 for eMMC and MMC2 for SD-card as other Exynos-based boards do.
This allows to use common code to get MMC device id based on the XOM[7:5]
pins.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0006-arm-dts-exynos-Use-common-alias-for-Odroid-U3-X2-MMC.patch
Marek Szyprowski [Thu, 16 Jan 2020 15:25:34 +0000 (16:25 +0100)]
[PATCH 3/5] arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
Card detect line for SD-card on Odroid U3/X2 boards are active low, so
add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't
support specifying line polarity. This restores S5P_SDHCI driver operation
on Odroid U3/X2 boards.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0005-arm-dts-exynos-Fix-card-detect-polarity-for-SD-card-.patch
Marek Szyprowski [Thu, 16 Jan 2020 13:46:04 +0000 (14:46 +0100)]
[PATCH 1/5] arm: exynos: Use proper PMIC device names
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect enable power regulators on the supported Exynos boards to
use proper PMIC device device name then.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Reviewed-by: Lukasz Majewski <lukma@denx.de> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0003-arm-exynos-Use-proper-PMIC-device-names.patch
Marek Szyprowski [Tue, 14 Jan 2020 14:04:20 +0000 (15:04 +0100)]
[PATCH] arm: exynos: Use proper ADC device name
Since commit 4213609cc7 ("drivers: core: use strcmp when find device by
name") one has to provide full name to get requested object. Fix the code
used to detect Odroid board revision to use proper ADC device name then.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Anand Moon <linux.amoon@gmail.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0002-arm-exynos-Use-proper-ADC-device-name.patch
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116 Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
u-boot currently fails to build from source on sh4 since the
linker name prefix defined in arch/sh/config.mk is outdated.
On current Debian installations, the binaries of the GNU
toolchain are named using the triplett scheme
$arch-$kernel-$toolchain. Thus, on sh4, the proper name
is "sh4-linux-gnu-ld" instead of "sh4-linux-ld". This
patch updates build configuration on sh4 to reflect that.
The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
to Kconfig.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name qemu-riscv64_smode-sifive-fu540-fix-extlinux-define-.patch
Leigh Brown [Wed, 27 Feb 2019 11:32:16 +0000 (11:32 +0000)]
[PATCH] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug
Hello,
Vagrant Cascadian asked for people to test the version of u-boot packaged
for Debian Buster. I tested u-boot on my Dreamplug and found it was not
working correctly. I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.
The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
I don't have much knowledge of ARM caching, but the following patch makes
it work again on my Dreamplug.
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name Commit-ARM-CPU-arm926ejs-Consolidate-cache-routines-.patch
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116 Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
u-boot currently fails to build from source on sh4 since the
linker name prefix defined in arch/sh/config.mk is outdated.
On current Debian installations, the binaries of the GNU
toolchain are named using the triplett scheme
$arch-$kernel-$toolchain. Thus, on sh4, the proper name
is "sh4-linux-gnu-ld" instead of "sh4-linux-ld". This
patch updates build configuration on sh4 to reflect that.
* New upstream release.
* debian/rules: Do not call qcom wrapper script.
* debian/control: Drop Build-Depends on "skales", removed from testing.
* u-boot-rockchip: Use python3 in rockchip_make_fit_atf.
* generate-rksd: Only generate SPL rksd on targets not using TPL.
* Add build profile pkg.uboot.subarch.* to build only subsets of
packages.
* [arm64] u-boot-rockchip: Add arm-trusted-firmware and u-boot-tools to
Recommends.
Leigh Brown [Wed, 27 Feb 2019 11:32:16 +0000 (11:32 +0000)]
Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug
Hello,
Vagrant Cascadian asked for people to test the version of u-boot packaged
for Debian Buster. I tested u-boot on my Dreamplug and found it was not
working correctly. I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.
The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
I don't have much knowledge of ARM caching, but the following patch makes
it work again on my Dreamplug.
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name Commit-ARM-CPU-arm926ejs-Consolidate-cache-routines-.patch
Chris Packham [Thu, 28 Feb 2019 07:53:23 +0000 (20:53 +1300)]
ARM: kirkwood: add spi0 alias for dreamplug
The conversion to DM_SPI managed to break accessing the environment on
dreamplug. This is because the environment code relies on being to able
to select the SPI device based on the sequence number. Add an alias so
that the spi0 bus gets sequence number 0.
Reported-by: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Chris Packham <judge.packham@gmail.com>
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name ARM-kirkwood-add-spi0-alias-for-dreamplug.patch
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116 Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch
While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.
Assuming U-Boot with RANDOM_UUID=y is deployed on a large number of
devices, all those devices would essentially expose the same UUID,
breaking the assumption of system/RFS/application designers who rely
on UUID as being globally unique (e.g. a database using UUID as key
would alias/mix up entries/records due to duplicated UUID).
The root cause seems to be simply _not_ seeding PRNG before generating
a random value. It turns out this belongs to an established class of
PRNG-specific problems, commonly known as "unseeded randomness", for
which I am able to find below bugs/CVE/CWE:
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-0285
("CVE-2015-0285 openssl: handshake with unseeded PRNG")
- https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-9019
("CVE-2015-9019 libxslt: math.random() in xslt uses unseeded
randomness")
- https://cwe.mitre.org/data/definitions/336.html
("CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)")
The first revision [1] of this patch updated the seed based on the
output of get_timer(), similar to [4].
There are two problems with this approach:
- get_timer() has a poor _ms_ resolution
- when gen_rand_uuid() is called in a loop, get_timer() returns the
same result, leading to the same seed being passed to srand(),
leading to the same uuid being generated for several partitions
with different names
The above drawbacks have been addressed in the second version [2].
In its third revision (current), the patch reworded the description
and summary line to emphasize it is a *fix* rather than an improvement.
Testing [3] consisted of running 'gpt write mmc 1 $partitions' in a
loop on R-Car3 for several minutes, collecting 8844 randomly generated
UUIDS. Two consecutive cold boots are concatenated in the log.
As a result, all uuid values are unique (scripted check).
Thanks to Roman, who reported the issue and provided support in fixing.
Benjamin Lim [Fri, 29 Mar 2019 11:29:45 +0000 (07:29 -0400)]
Fix ext4 block group descriptor sizing
Ext4 allows for arbitrarily sized block group descriptors when 64-bit
addressing is enabled, which was previously not properly supported. This
patch dynamically allocates a chunk of memory of the correct size.
Signed-off-by: Benjamin Lim <jarsp.ctf@gmail.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name Fix-ext4-block-group-descriptor-sizing.patch
Marek Vasut [Wed, 6 Feb 2019 12:19:29 +0000 (13:19 +0100)]
fs: ext4: Unmount FS in do_fs_type()
Unlike other generic FS accessors, fs_get_info() does not call fs_close()
at the end of it's operation. Thus, using fs_get_info() in do_fs_type()
without calling fs_close() causes potential memory leak by creating new
filesystem structures on each call of do_fs_type().
The test case to trigger this problem is as follows. It is required to
have ext4 filesystem on the first partition of the SDMMC device, since
ext4 requires stateful mount and causes memory allocation.
=> while true ; do mmc rescan ; fstype mmc 1 ; done
Eventually, the mounting of ext4 will fail due to malloc failures
and the filesystem will not be correctly detected.
This patch fixes the problem by adding the missing fs_close().
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name fs-ext4-Unmount-FS-in-do_fs_type.patch
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
Leigh Brown [Wed, 27 Feb 2019 11:32:16 +0000 (11:32 +0000)]
Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug
Hello,
Vagrant Cascadian asked for people to test the version of u-boot packaged
for Debian Buster. I tested u-boot on my Dreamplug and found it was not
working correctly. I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.
The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
I don't have much knowledge of ARM caching, but the following patch makes
it work again on my Dreamplug.
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name Commit-ARM-CPU-arm926ejs-Consolidate-cache-routines-.patch
Chris Packham [Thu, 28 Feb 2019 07:53:23 +0000 (20:53 +1300)]
ARM: kirkwood: add spi0 alias for dreamplug
The conversion to DM_SPI managed to break accessing the environment on
dreamplug. This is because the environment code relies on being to able
to select the SPI device based on the sequence number. Add an alias so
that the spi0 bus gets sequence number 0.
Reported-by: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Chris Packham <judge.packham@gmail.com>
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name ARM-kirkwood-add-spi0-alias-for-dreamplug.patch
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116 Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch
Marek Vasut [Wed, 6 Feb 2019 12:19:29 +0000 (13:19 +0100)]
fs: ext4: Unmount FS in do_fs_type()
Unlike other generic FS accessors, fs_get_info() does not call fs_close()
at the end of it's operation. Thus, using fs_get_info() in do_fs_type()
without calling fs_close() causes potential memory leak by creating new
filesystem structures on each call of do_fs_type().
The test case to trigger this problem is as follows. It is required to
have ext4 filesystem on the first partition of the SDMMC device, since
ext4 requires stateful mount and causes memory allocation.
=> while true ; do mmc rescan ; fstype mmc 1 ; done
Eventually, the mounting of ext4 will fail due to malloc failures
and the filesystem will not be correctly detected.
This patch fixes the problem by adding the missing fs_close().
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name fs-ext4-Unmount-FS-in-do_fs_type.patch
Ensure that CONFIG_SANDBOX is set when running "make env", avoiding a
failure to build caused by config_distro_bootcmd.h following the wrong
codepath...
Gbp-Pq: Name ensure-config-sandbox-for-make-env.patch
[ Jonas Smedegaard ]
* Add patch cherry-picked upstream to add i2c initialization for sun50i.
* Add patch by Vasily Khoruzhick to support Olimex Teres-I DIY laptop.
* Enable teres_i target in u-boot-sunxi (Closes: #926040).
Leigh Brown [Wed, 27 Feb 2019 11:32:16 +0000 (11:32 +0000)]
Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug
Hello,
Vagrant Cascadian asked for people to test the version of u-boot packaged
for Debian Buster. I tested u-boot on my Dreamplug and found it was not
working correctly. I raised a bug for Debian[1] but I have also tested
with the mainline version of u-boot and found the same issues.
The first issue is that the following commit caused u-boot to no longer
be able to access usb storage on the Dreamplug:
ARM: CPU: arm926ejs: Consolidate cache routines to common file
Four different boards had different options for enabling cache
that were virtually all the same. This consolidates these
common functions into arch/arm/cpu/arm926ejs/cache.c
This also has the positive side-effect of enabling cache on
the Davinci (da850) boards.
Signed-off-by: Adam Ford <aford173@gmail.com>
[trini: Add mach-at91 to the list of consolidations] Signed-off-by: Tom Rini <trini@konsulko.com>
I don't have much knowledge of ARM caching, but the following patch makes
it work again on my Dreamplug.
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name Commit-ARM-CPU-arm926ejs-Consolidate-cache-routines-.patch
Chris Packham [Thu, 28 Feb 2019 07:53:23 +0000 (20:53 +1300)]
ARM: kirkwood: add spi0 alias for dreamplug
The conversion to DM_SPI managed to break accessing the environment on
dreamplug. This is because the environment code relies on being to able
to select the SPI device based on the sequence number. Add an alias so
that the spi0 bus gets sequence number 0.
Reported-by: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Chris Packham <judge.packham@gmail.com>
Gbp-Pq: Topic dreamplug
Gbp-Pq: Name ARM-kirkwood-add-spi0-alias-for-dreamplug.patch
Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.
Bug-Debian: https://bugs.debian.org/920116 Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch
Marek Vasut [Wed, 6 Feb 2019 12:19:29 +0000 (13:19 +0100)]
fs: ext4: Unmount FS in do_fs_type()
Unlike other generic FS accessors, fs_get_info() does not call fs_close()
at the end of it's operation. Thus, using fs_get_info() in do_fs_type()
without calling fs_close() causes potential memory leak by creating new
filesystem structures on each call of do_fs_type().
The test case to trigger this problem is as follows. It is required to
have ext4 filesystem on the first partition of the SDMMC device, since
ext4 requires stateful mount and causes memory allocation.
=> while true ; do mmc rescan ; fstype mmc 1 ; done
Eventually, the mounting of ext4 will fail due to malloc failures
and the filesystem will not be correctly detected.
This patch fixes the problem by adding the missing fs_close().
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
Gbp-Pq: Topic upstream
Gbp-Pq: Name fs-ext4-Unmount-FS-in-do_fs_type.patch
projects / u-boot.git / log